The Original Shareware 1.1/The Original Shareware (WeMake CDs)(Volume 1.1)(CDs, Inc)(1993).iso/7/telenet.zip/TIPS.TXT

Text File | 1989-03-04 | 20KB | 383 lines

a

1/18/87                TROUBLESHOOTING PC PURSUIT CALLS
               (Tips for helping Cust. Svc. help Pursuit callers)

   This is a list of typical questions about PC Pursuit and some answers that
should help.  I will not swear that everything--or anything--is accurate.
However, most of the explanations will, at least, help most PC Pursuit
customers.


GENERAL RULES
"""""""""""""
   First, listen to what the customer is saying.  Some of these guys have more
experience with data communications than anyone in this building, let alone in
this department.  They will obviously not be impressed if you run on autopilot
through the typical "are you at 8 bits and no parity" sort of question.  Calls
tend to be one of two types: general, simple informational questions and
specific technical problems.  If you treat one of the latter as if it were one
of the former, you will do little to convice the customer that you are steering
him correctly.
   Second, don't be too eager to dump the customer onto someone else or off the
line.  This will make life easier for whoever has to eventually solve the
problem.


SPECIFIC PROBLEMS
"""""""""""""""""
"I can't connect to a port; I keep getting D/DCWAS/12 [or whatever] BUSY."
----------------------------------------------------------------------------

   Explain that these are legitimate busies and that port expansion, both in
adding new cities and in expanding existing rotaries, is underway.
We *will* be adding several hundred new lines to the system.  Many cities
have already been upgraded, and more are being completed all the time.


"I connect to a port but I get hung.  Not even ATZ will appear."
------------------------------------------------------------------

   If they're currently in the frozen port (some users know enough to hold it
open and call us on another line), run a port scan to see where they're
connected.  Reset the port to knock them out, C-space to it, and if you can't
clear the trouble, busy it out and send a ticket to the field.  (This should be
old hat by now, with the troubles we've recently found in the new DC modems.)

   If they are not connected, your only approach is to try to connect directly
to each port and see if any refuses to respond.  If you can't find a malfunc-
tioning modem, make sure the user was entering "ATZ" in capital letters.


"I connect to a port and enter ATZ but everything seems to hang."
--------------------------------------------------------------------
   Check to see if they are using a Hayes compatible modem.  The PCP modems use
a limited subset of the Hayes "AT" commands.  In theory, a working Hayes or
compatible modem will ignore these commands while in a data transfer state.  To
place such a modem in command mode, the user must rapidly enter three plus
signs (+) in a row and then wait until the modem acknowledges the command
before entering any more data.

   However, malfunctioning modems or some of the not-quite-compatible (usually
cheaper) modems will act on "AT" commands from within data transfer.  When the
user enters the ATZ command to wake up the PCP modem, it instead resets the
user's modem, usually dropping the connection.  This would also happen if the
string "ATZ" was encountered during a file transfer.

   There's not a lot we can do to diagnose this, and PCP users
take none too kindly to the suggestion that their bargain modems are no
bargain.  As a test, have the user connect to a port and enter one of the Hayes
commands not supported by the PCP modems--for instance, ATH0, which hangs up
the modem, or ATH1, which "lifts" it off the hook.  If they are actually
talking to the PCP modem, it will respond with an "OK" and do nothing else; if
they are talking to their own modem, it will drop carrier.

   To use PCP successfully, they will either (1) have to replace or repair
their modem, (2) find a way to disable its break to command mode, or (3) try
to throw the PCP port into Racal-Vadic mode (with a Ctrl-E).  Note that the
latter solution does not always work unless the modem has been reset with an
ATZ command--which, of course, is out of the question--and may not always be an
option, depending on hardware manufacturer and version.

   I have yet to find an instance of this that was not trouble on the
customer's end, but I expect we will.



"I try to call this number from a PCP modem and I get a busy.  I dial it
immediately after hanging up [or from another line] and I get through.   I try
it again on PCP and get a busy."
--------------------------------------------------------------------------------

   First, make sure that the number they are dialing is within the accepted
exchanges for a given city (see the list in the PCP guide).  Note that there
are a few exchanges that can be reached that are not on the list; a slightly
more up-to-date list is available on the Net Exchange BBS.

   If the number should be valid, see if you can isolate the port the user is
calling from.  Connect to that port, issue "ATZ", and send the modem a Ctrl-E
and carriage return.  This will throw the modem into Racal-Vadic mode, which
provides better diagnostics than Hayes mode.  Try to dial the number and see
what transpires.  Racal-Vadic mode will report on the absence of a dial tone,
each ring as it occurs, and the ultimate outcome of the call.  Take appropriate
action.  (Also, the new modems--the new ones in DC, not the ones that will be
used for the expansion--give a "NO DIAL TONE" message from within Hayes
emulation mode.)

   If the user is certain that the exchange is local to the PCP city, ask him
to leave a message to the SysOp (i.e., Dave) on the Net Exchange board.
If you get a connection or what appears to be a legitimate busy, inform the
customer and chalk it up to chance and a busy BBS.



"Sometimes when I connect to a port, I get a message that says 'MANUAL ANSWER'
and I can't do anything but disconnect."
-------------------------------------------------------------------------------

   Since the Racal-Vadic mode provides better diagnostics (see above), many
users shift into it before dialing their BBS.  If they terminate abnormally
(that is, if the session, not the user, terminates abnormally), the modem may
be left in Racal-Vadic mode.

   For instance, User A uses Racal-Vadic mode to call a board.  He then gets
bumped off the line (or perhaps hangs up before returning the modem to Hayes
emulation) and User B connects to the port before the modem has a chance to
reset (assuming it resets at all).  The modem has sent the Racal-Vadic prompt--
an asterisk--to User A and is waiting for a command.  User B sees no response--
the prompt has already been sent--so he assumes the modem is in Hayes mode.  He
enters "ATZ" and waits for the "OK".  (To make matters worse, perhaps he is
using a command script that needs to "see" an "OK" before proceeding.)

   The modem, currently ignorant of Hayes commands, interprets the "A" of the
"ATZ" as being the Racal-Vadic command to answer a call manually; that is, to
take the line off-hook and respond to the call.  It does so, having first sent
the user the message "MANUAL ANSWER."  Since people rarely dial *into* a PC
Pursuit line, nothing happens and the modem just sits.

   To get the user out of this trap, have him enter carriage returns until the
modem drops the line and prompts him with another "*".  At this prompt, have
the user enter "I".  This is a nonintuitive command--the "I" stands for "IDLE"
--but it has the happy result of returning the modem to Hayes mode.

There is a file called rvprimer.txt on the Net Exchange which describes the
Racal-Vadic mode.



"I call Exec PC but I cannot break to command mode" or "I call Exec PC but I
get an echo back at the end of each line" or "I call Exec PC but downloads
won't work."
-----------------------------------------------------------------------------

   I thought we had this one licked, but I didn't know enough about X.3
parameters....
   First, to remove the echo and to enable downloads, the user *must* break to
command mode and set several of the X.3 parameters.  This is explained in the
PCP newsletter and in a file on the Exec PC BBS.  The user needs to issue the
following command

SET? 1:0,2:0,4:2,7:8,10:0,0:0,57:1,63:0

and then CONTinue back into the transfer.
   If the user is calling in at 8-bit transparency (that is, he issues
<CR>D<CR> or <CR>H<CR> at the hunt-confirm stage), he will need to set ITI
parameter 57 to enable break to command mode once he connects to Exec PC.  This
is done by entering

SET? 0:0,57:1

at the first "@".
   However, what I didn't know was that the caller's PAD will return to the
default ITI parameters following the call clear--even if the call is cleared
because the port is busy.  Since it is almost impossible to connect directly
into Exec PC on the first try--I've spent nearly an hour trying, every 15
seconds, to connect into one of the three ports before getting in--most users
have had their ITI parameter 57 return to zero before they are able to connect
to exec PC.  They will have to issue the SET? 0:0,57:1 command before *each*
attempt to call Exec PC.



"I use XMODEM across the system and transfers take twice [or thrice] as long as
they should.  Why?"
--------------------------------------------------------------------------------

   As best as I can tell, the information we were passed from the Net Exchange
BBS was well-meaning but wrong.  Here is the scenario as I figger it--someone
let me know if I'm wrong, too.

   XMODEM sends data in a 132-byte block that resembles a mini-packet:

   <-------------------------  Direction of transmission

   [SOH] [#] [#] [DATA] [CHK]
     |    |   |    |      |___ "Checksum" (kinda) for error-detection
     |    |   |    |__________ 128 bytes of data
     |    |   |_______________ "One's complement" of block number
     |    |___________________ Block number
     |________________________ Start of header (ASCII 01)


This closely matches the size of a Telenet packet (generally 128 bytes) and
can, for our purposes, be considered a packet's worth of data.  PC Pursuit is
set to forward data only on full packets and on expiration of idle timers
(which are set for 1/10 second).

  The delay occurs because a connection through PC Pursuit goes through four
modems and two entirely separate data transmissions.  Each block of data must
undergo the following (assuming a download from the BBS to the user):
 _____           _________           __________
|     |____     (         )____     |          |
| BBS |    /____(   PDN   )    /____| PCP user |
|_____|         (_________)         |__________|

       |_______| |_______| |_______|
           |         |         |_____  1.1 seconds
           |         |_______________  Variable (0.1 to 1+ seconds)
           |_________________________  1.1 seconds


That's potentially 3+ seconds to transfer data that would take slightly over
1 second to transmit in a direct connection--maybe 35% efficiency.

   To make matters worse, the acknowledgment (ACK) from the user to the BBS may
take upwards of a second--instead of a fraction of a second--to be transmitted
back into the network, have idle timers expire, be forwarded to the outdialer,
and be transmitted to the BBS.  As you can see, though, the real delay is *not*
because of the delay in sending the ACK, but because the block size and packet
size so nearly match, the two computers are almost never working
simultaneously.

   A protocol that uses a larger block size--YMODEM, for instance--will run
faster over the system, but not because it needs fewer acknowledgements.
Instead, while sending the larger block, it causes data forwarding on a full-
packet condition.  After the first packet gets sent, both machines are doing
work for most of the rest of the transmission, as such:

                      BBS                           USER
                      """                           """"
Start of 1K block     Sends packet 1                Does nothing
                      Sends packet 2                Receives packet 1
                      Sends packet 3                Receives packet 2
                      Sends packet 4                Receives packet 3
                      Sends packet 5                Receives packet 4
                      Sends packet 6                Receives packet 5
                      Sends packet 7                Receives packet 6
End of 1K block       Sends packet 8                Receives packet 7
                      Does nothing                  Receives packet 8


(Of course, the BBS is not really sending the *packet*, just a packet's worth
of data.)  In effect, YMODEM wastes only 2 of every 9 128-byte transfers; it
should run at about 75% efficiency.  In addition, since it only has a single
ACK per kilobyte (instead of 8), less time is spent in waiting for the idle
timer to expire.

   Of course, to make things more confusing, there are XMODEM packages using
256-byte and 1K blocks and XMODEM packages that allow a "window" of
unacknowledged blocks to be sent, among other flavors.  If the user is using
one of the strange XMODEMs, he'll usually know enough to mention it.

   Recently, the default parameters for the PC Pursuit ports were changed; by
whom, I don't know.  For best results, users should break to command mode and
set X.3 parameters 1 and 10 to 0 (disables break to command mode and word wrap)
and set ITI parameter 57 to 1 and parameter 63 to 0 (enable 8-bit transparent
mode).  This is all done with similar commands as those issued when connecting
to Exec PC.



"I can't use PUNTER protocol across the network."
-------------------------------------------------

   I have sent word (through a friend) for Steve Punter to call me to discuss
what might be going wrong with his procotol for Commodore machines.  However,
as best as I can tell, PUNTER protocol has a severely restrictive time-out
setting--the amount of time it will wait for an acknowledgement back from the
receiving site before assuming a block was lost and retransmitting it.  As the
diagram above shows, PC Pursuit introduces a lot of delay into the loop, and
this is too much for the BBS to take.  It starts to send the "lost" block
again; the receiving station finally receives and acknowledges the block; and
everything falls apart.  (This is complete assumption, by the way; I haven't
been able to find any hard info on PUNTER, although I am told it works in 256-
byte blocks.)  If this is true, I doubt PUNTER would even work over a satellite
long-distance connection, so PUNTER BBSs will probably soon offer a "relaxed"
PUNTER.  Often, Commodore users having no luck with PUNTER have been able to
run successful XMODEM transfers.



"I have no [or little] trouble downloading from a BBS, but my uploads often
fail."
-----------------------------------------------------------------------------

   This also seems to be related to time-out periods, but I'm not sure.
Because a 132-byte block will be sent in 2 packets and, thus, activity on
sending and receiving ends may overlap slightly, it is conceivable that the
delay between sending the last byte of a data block and receiving the ACK would
be a tiny bit less than the delay between sending the ACK and receiving the
first byte of the next block.  (Note: Here I am grasping for straws.)  If the
BBS has a particularly unforgiving time-out setting, it might reject the block
or get out of sync (see the PUNTER hypothesis, above).  Several Texas
Instrument computer users have been able to trick PC Pursuit into handling
transfers by calling into the networkj at 300 baud but calling out at 1200; I
haven't the foggiest idea why this works, unless the time-out period is
relatively more relaxed at the faster speed.



"I can't get the listing of BBSs on the Net Exchange BBS to download" or "I've
downloaded the listing of BBSs but can't read it; it's garbage."
-------------------------------------------------------------------------------

   Files with the extension .SQ have been squeezed; there are a number of
slightly different programs and variations for doing this, some compatible with
others.  Many machines have access to some sort of squeezing utility; whether
or not the file downloaded is in the proper format is another question.

   Files with the extension .LBR have been libraried; this procedure combines a
number of files into a single file, usually without data compression.  The
resulting file is easier to download and catalog than the individual files
would be, and takes up slightly less room.  LU is the main program for
librarying files in the IBM-compatible environment; I know of no comparable
programs for other machines.

   Files with the extension .ARC have been archived; this is a technique that
both squeezes and libraries files.  Files are usually archived with ARC, a
user-supported program distributed by System Enhancement Associates.  As far as
I know, there is only an official ARC for IBM-style computers; I think, but am
not sure, that there is a compatible program for CP/M-based machines (like the
Kaypro) and machines running Un*x.  I know of no other computers that can make
use of .ARC files.



"What do NO CARRIER and NO ERROR CONTROL mean?  I saw them in a recent
connection to Wash D.C. (D/DCWAS)."
------------------------------------------------------------------------

The modems in Wash D.C. are the new Vadic modems, which will also
support 2400 outdial when deployed.  These new modems have expanded response
messages.  NO CARRIER is seen in the Hayes mode when carrier has been
dropped between the Telenet outdial modem and the target BBS which the
user dialed.  The user still has control of the modem and can dial a
new number in the city if desired.

   NO ERROR CONTROL - is displayed whenever one of the new modems is
connected on-line with the target BBS.  It simply means that the outdial
modem is not in the MNP reliable modem (with local loop error protection).
You see, MNP is built into these new modems, and that means that when these
new modems call another modem with MNP in it, they will hand-shake and
come up in the Microcom reliable mode - which provides error protection in
the local phone loop.  If it is not using MNP and says NO ERROR CONTROL,
the call will still go through just fine to the remote BBS.



"How do I get the Racal-Vadic command mode?"
----------------------------------------------

The Hayes command mode is the only officially supported command mode for
PC Pursuit at this time - to simplify support and ease of use for users.
However, users may use the R-V mode, which does give some better
response messages (such as "Dialing", and also has re-dial).  To get
to the R-V mode, type ATZ to get the OK, then  ctrl-E  and you should
wake up the modem into the R-V mode as it responds "Hello, I'm ready"
with a  * .   Type ? (cr) for a list of the commands available.
When done with your session, the modem will reset itself into the
Hayes mode as you enter  I (cr) to Idle the modem.  (or depending on
how you disconnect, it will automatically reset to Hayes mode for the
next user within 10 - 100 seconds).



Time left = 56 minutes and 18 seconds
Current download area = pcp
Current upload area = upload
Allowable daily download limit = 5472770 bytes

A(rea change)      D(ownload)         F(ile list)        M(ain menu)
G(oodbye)          T(oggle page)      ?( help )

Commands: A,D,F,M,G,T,? ===>